Controlling Global Code Motion

Traditional global optimizers avoid moving instructions in cases that may cause them to be executed along control flow paths where they would not have been in the original program. However, GCM performs such motion, called speculative code motion because the instructions moved are executed based on speculation that they actually prove useful. By default, GCM is very conservative in its speculations. Most of the options in the -GCM: group control the sorts of speculation that are to be allowed.

Valid speculative code motion must normally avoid moving operations that may cause run-time traps. As a result, turning off certain traps at run time enables more motion. See the target environment option -TENV:X=n for general control over the exception environment.

-GCM:aggressive_speculation[=(ON|OFF)]

GCM normally tries not to move instructions to basic blocks that are already using most of the instruction execution resources available, since doing so will likely extend the execution time of the block. This option minimizes that bias, which often helps floating point intensive code.

-GCM:array_speculation[=(ON|OFF)]

A form of speculation that is often very effective is called bottom loading. It involves moving instructions from the top of a loop body to both the block before the loop (for the first iteration) and to the end of the loop body (which executes them at the end of one iteration so that they are ready early for the next iteration). Bottom loading, however, means that the instructions are executed one or more extra times in the last iteration(s) of the loop. If the instructions moved are loading elements of an array, this may cause extra accesses beyond the end of the array.

This option enables such accesses a small distance beyond the end of the array. The compiler attempts to pad arrays to guarantee that such accesses won't cause memory faults, but it may not always be able to do so, so this option must be used with care.

-GCM:pointer_speculation[=(ON|OFF)]

This option allows speculative motion of loads of two kinds, both involving pointer usage. The first is to allow motion of loads through pointers that may be NULL. In order to prevent this from causing memory faults, the compiler causes page zero of the address space to be mapped at run time. Since this may prevent some truly invalid references from causing faults, avoid this option during debugging.

The second form involves moving a reference like *(p+n), for a small integer n, to a block that already contains a reference to *p. The assumption involved is that if p is a valid address, p+n is too.

Consider an example:

...

if ( p->next != NULL ) {

sum += p->next->val;

} else {

sum += p->final_val;

}

...

If this option is set, the load of p->next->val can be moved before the if (it is through a potentially NULL pointer), as can the load of p->final_val (it is offset by a small amount from the p->next reference).

-GCM:static_load_speculation[=(ON|OFF)]

Allow the speculative motion of loads from static data areas. Since such areas are known to be allocated, such motion cannot cause new faults except page faults or cache misses. As a result, it is generally safe, although it may hurt performance if it causes unnecessary page faults or cache misses.

-GCM:postpass[=(ON|OFF)]

GCM is implemented in two passes, one before instruction scheduling and register allocation, and one after, currently enabled at optimization -O2 and above. These options allow either or both of the passes to be enabled or disabled. The two passes are complementary in effect, often improving code more in combination than the sum of their individual improvements, so enabling just one is not recommended.